This chapter describes how to use the Thin Server Feature (TSF) in the IBM 2216.
A Network Station is similar to a personal computer (PC), having a keyboard, display, and a mouse. The main difference between a Network Station and a PC is that the Network Station files reside on a network server rather than on a hard drive inside of your machine. The Network Station presents you a graphical user interface (GUI), which provides access to many resources, including emulators, remote X applications, Web browsers, applications, and printers.
The Network Station communicates using TCP/IP over a token-ring or Ethernet connection to the server. The Network Station power-on process is:
Refer to IBM Network Station Manager Installation and Use for more information about Network Stations.
One physical device may function as the BootP/DHCP server, the boot server, the terminal configuration server, and the authentication server, or each server may be a separate device. For example, you may have a Network Station connected to an AS/400(R) and the AS/400 acts as the BootP server, base code server, terminal configuration server, and authentication server. Alternatively, each server may be a separate physical box. For example, the Network Station may be connected to a network where a Windows(R) NT server is its DHCP server, an AS/400 is its base code server, another AS/400 is its terminal configuration server, and yet another AS/400 is its authentication server.
The Thin Server feature allows the 2216 to be a base code server. One example of why using the TSF would be desirable is illustrated by Figure 49 and Figure 50. In Figure 49, any file which the Network Station requires will be downloaded from the single server. When the Network Station is powered on, the download consists of several megabytes. This could be very demanding on a network infrastructure, as well as the device acting as the base code/terminal configuration server or authentication server, especially if many Network Stations are powered on simultaneously. Figure 50 shows the network with a Thin Server used at the remote site. Many of the files associated with the Network Station boot code will be cached by the Thin Server. When the Network Station is powered on, most of the boot code will be loaded from the Thin Server and only a small amount of data will need to be transported across the network infrastructure. This reduced processing on any single server lowers network traffic and reduces the time necessary complete the power on of a Network Station.
Since files cached by the Thin Server are copies of files that reside on the master file server, as the version on the master file server gets modified, the Thin Server needs to update its version of that file. The Thin Server will verify that all of the cached files are identical to the master file server version of those files when:
Figure 49. Remote Network Station without a Thin Server
|
Figure 50. Remote Network Station with a Thin Server
 |
You have two options for BootP/DHCP Server support:
Refer to IBM Network Station Manager Installation and Use for more information about multiple server environments.
The protocols used to communicate between the
Network Station and its servers will be determined either by the BootP/DHCP
configuration or by the Network Station NVRAM configuration. In either
case, the protocols which the Network Station uses must be compatible with how
the TSF is configured.
If the TSF is configured to use Remote File System (RFS) to communicate
with the master file server, then it will respond to RFS and TFTP requests
from the Network Stations and the TSF will not respond to any Network File
System (NFS) requests from Network Stations.
Similarly, if the TSF is configured to use NFS to communicate with the
master file server, then it will respond to NFS and TFTP requests from the
Network Stations and the TSF will not respond to any RFS requests from Network
Stations.
The TSF establishes a connection to the AS/400 using RFS. When a
Network Station makes a request to open a file, the TSF forwards that request
to the AS/400 for authorization. If the Network Station is not
authorized, TSF will not send the requested file to the Network
Station. If the Network Station is authorized, and the AS/400 version
of the requested file differs from the version stored on the IBM 2216 TSF, the
Network Station request is relayed to the AS/400. If the file on the
AS/400 is the same version as the file the TSF has cached, then the TSF will
serve that file to the Network Station.
If the TSF is configured for disconnected mode, the TSF handles all of the
Network Station traffic locally and either serves the file if it is cached, or
responds File Not Found if it is not cached. Thus, it is imperative
that all files that the Network Station is requesting be cached. The
TSF connects to the master file server to perform the refreshes, but no file
opens or per file authentication is relayed to the master file
server. If the TSF connection to the AS/400 is unavailable, or the TSF is in
disconnected mode, then the TSF serves the files that it currently has cached
to the Network Station.
If TFTP is being used to communicate between the Network Station and the
TSF, the TSF will serve Network Station requests for files if those files are
available. No verification of version is made between the TSF and the
master file server. If the file is not available in the TSF cache, the
request from the Network Station is forwarded to the master file
server.
If the TSF is configured for disconnected mode, TSF handles all of the
Network Station requests locally. If a file is not available in the TSF
cache, the TSF responds File Not Found instead of relaying the request to the
master file server.
If NFS is being used to communicate between the Network Station and the
TSF, then when a Network Station makes a request for a file, the TSF starts
serving that file if it is cached. Simultaneously, it verifies that the
file is the same version as the master file server. If not, then the
TSF terminates the serving of the file and immediately starts downloading the
new version from the master file server.
If the TSF is configured for disconnected mode, the TSF does not verify
each file as it is requested.
If the TSF does not have the file cached, then the TSF responds File Not Found. In addition, if the requested file resides in a directory for which the TSF has been configured with include subdirectories or resides in a sub-directory under such a configured directory, then the TSF starts caching the file, if the file exists on the master file server.
The protocol used for file caching on the network device is determined by
the configuration of TSF. You designate a master server using the
add master-file-server command.
The TSF provides for configuration of two master file servers, a file
server and a secondary file server. The secondary file server is a
backup file server. For both RFS and NFS master file servers, you are prompted for the address
of a file server and a secondary file server. The file server address
is required; the secondary file server address is optional. The
file server should be the primary master file server for this TSF. If
more than one server is running NSM and you want to specify a backup or
alternate file server that the TSF is to use when the server specified as the
file server is unavailable, then you may specify a secondary file
server. If no secondary master file server exists, set the secondary
file server address to 0.0.0.0. It is recommended
that both master file servers be running the same version of NSM, and if using
RFS it is recommended that both pre-load lists be identical; otherwise
the Network Station behavior may change when the TSF switches to the secondary
master file server. The switching or selection of either the file server or the secondary file
server is controlled by the Talk 6 set selection command.
You may set the selection to primary, secondary, or automatic. Setting
the selection to primary causes the secondary file server to be ignored;
only the primary is contacted. If the primary server is not contacted
after the configured number of retries, then the TSF stops trying to contact
it until the next refresh. Setting the selection to secondary causes
the primary file server address to be ignored; only the secondary file
server is contacted. If the secondary file server is not contacted
after the configured number of retries, then the TSF stops trying to contact
it until the next refresh. Setting the selection to automatic causes
TSF to try to contact the primary file server. If it is not contacted
after the configured number of retries, then the TSF automatically tries to
connect to the secondary file server.
If you specify rfs, you are prompted to specify a pre-load list
file name. The pre-load list is an ASCII file that specifies the
fully-qualified file name of every file that the TSF is to cache.
If you specify nfs, you are prompted for directory names to be
cached (some defaults may be provided). When you specify a directory,
you are prompted to specify whether or not to include subdirectories.
Specifying no (do not include subdirectories) causes the TSF to
pre-load all files in the specified directory into the TSF cache.
Specifying yes (include subdirectories) causes the TSF to
not pre-load any files from that directory, but instead to
dynamically retrieve files from that directory and any of its subdirectories
as Network Stations request those files.
Files that are in the process of being refreshed are not sent to the Network Station during this process.
When the TSF is installed, there are several configurations beyond that of the TSF itself which may need to be considered. This section discusses the changes which may be necessary to the BootP/DHCP server, the master file server, the IBM 2216 BootP Relay, the IBM 2216 Internal IP address, and the IBM 2216 TSF configuration. An example of a Thin Server connecting to an AS/400 running Network Station Manager (NSM) Release 2.5 is discussed in "Sample Configuration".
The following sections describe the Thin Server environment configuration process:
The following are configuration recommendations to help you get the most from the TSF:
While the TSF does not require a hardfile, it will improve your performance if the TSF memory cache is configured too small (or cannot be configured large enough because of other functions in the 2216), and a hardfile will improve performance if the TSF or 2216 is restarted or reloaded.
The TSF will allow up to 200 RFS Network Station connections at one time. Simultaneously powering on more than 80 Network Stations may result in delays which exceed Network Station timeout values. Recovery may require the Network Station to be re-powered on.
While the TSF allows the master file server IP address to be any value, it is recommended that this be the address of a device that is running NSM so that the file structure is compatible with the Network Station and hence the TSF, and it can provide the files that the TSF will ask for.
This is required if you do not have a hardfile. If you do have a hardfile, memory access is much quicker than hardfile access. The amount of memory needed will vary depending on your specific environment. Use the Talk 5 list config command to determine how large your file set is at a particular instance in time . The value displayed for Hard File storage being used for Thin Server is the size of your file set in kilobytes. However, if different types of Network Stations or applications are added to or removed from your environment, this value may change.
This learning process may take several Network Station power-on sequences for TSF to identify all the needed files.
If the TSF is configured for disconnected mode, then all files requested from the TSF by the Network Station must be cached by the Thin Server. If using RFS, the pre-load list must contain all necessary files. If using NFS, the TSF must be configured to cache the appropriate directories. (The TSF will still learn/download files as necessary.) If the pre-load list or appropriate directories are not configured correctly, then Network Stations may not boot correctly. One way to ensure that the configuration is correct is to run TSF in Enabled mode and monitor the appropriate ELS messages and TSF counters before running in disconnected mode.
When running Network Station Manager Release 3, DHCP is required when you are using a Thin Server. If you are using an AS/400 as the master file server, then Network Station Manager Release 2.5 may be used, in which case BootP may be used instead of DHCP.
For BootP, only one server address can be specified. That address is specified by using the sa tag. This tag may or may not already exist in the BootP record for a given Network Station. If it does not exist, then create it and set the value to the 2216s Internal IP address. If it already exists, then change it to the 2216's Internal IP address.
For DHCP, the fields that may need to be modified when the Thin Server is used are as follows:
This value should be set to the IBM 2216 Internal IP address
If the Thin Server is being configured for a master-file-server type of NFS, then this must be either nfs or tftp. If the Thin Server is begin configured for a master-file-server type of RFS, then this must be either rfs/400 or tftp.
This address should be the same as the master-file-server IP address.
For more details about how NSs interact with BootP and DHCP, refer to IBM Network Station Manager Installation and Use.
For RFS, the pre-load list must be installed on the AS/400. The
preload list is available on the internet at
http://www.networking.ibm.com/netprod.html#routers.
You should ftp the LoadList.file from this site and place it in
/QIBM/ProdData/ OS400/NetStationRmtController on the AS/400.
The NetStationRmtController directory may need to be created.
For NFS, no special changes on the master server are necessary for the Thin
Server.
The IBM 2216's BootP Relay agent should be enabled and the appropriate BootP and DHCP servers should be configured so the BootP Relay will forward to those servers. Refer to Nways Multiprotocol Access Services Software User's Guide for more information.
If an Internal IP address already exists, no special change is necessary. If no Internal IP address is currently specified, one should be specified. Refer to Protocol Configuration and Monitoring Reference Volume 1 for more information.
Use the commands discussed in "Configuring and Monitoring Thin Server Function" to configure the Thin Server.
Minimally, the following commands must be entered:
The following example configures a TSF going to an AS/400 that is running Network Station Manager R2.5.
Figure 51. TSF Sample Configuration
 |
This discussion describes configuring the Thin Server Feature based on the above network and with the following assumptions:
c:\>ftp as400a Connected to as400a.raleigh.ibm.com. 220-QTCP at AS400A.RALEIGH.IBM.COM. 220 Connection will close if idle more than 5 minutes. Name (as400a:goofy): qsecofr 331 Enter password. Password: 230 QSECOFR logged on. ftp> ascii ftp> get qusrsys/qatodbtp.bootptab bootp.tab ftp> quit
OLD LINE -------- NSEN106:ip=192.9.250.36:bt=IBMNSM:ht=1:ha=00.00.A7.01.2E.35: sm=255.255.248.0:gw=192.9.250.6:bf=KERNEL: hd=/QIBM/PRODDATA/NETWORKSTATION MODIFIED LINE ------------- NSEN106:ip=192.9.250.36:bt=IBMNSM:ht=1:ha=00.00.A7.01.2E.35: sm=255.255.248.0:gw=192.9.250.6:bf=KERNEL: hd=/QIBM/PRODDATA/NETWORKSTATION:sa=192.9.250.6where 192.9.250.6 is the 2216 (TSF)'s Internal IP address
c:\> ftp as400a Connected to as400a.raleigh.ibm.com. 220-QTCP at AS400A.RALEIGH.IBM.COM. 220 Connection will close if idle more than 5 minutes. Name (as400a:goofy): qsecofr 331 Enter password. Password: 230 QSECOFR logged on. ftp> ascii ftp> put bootp.tab qusrsys/qatodbtp.bootptab ftp> quit
You can obtain a Pre-load list from the internet: http://www.networking.ibm.com/netprod.html#routers
Once you have the preload list you can "ftp" it to the AS/400.
ftp test400 Connected to test400.raleigh.ibm.com. Name (test400:root): qsecofr Enter password. Password: QSECOFR logged on.
ftp> cd / Current directory changed to /. ftp> cd qibm/proddata/os400/ Current directory changed to /qibm/proddata/os400. ftp> dir PORT subcommand request successful. List started. QTCP 34816 04/30/97 02:50:36 *DIR REXEC/ QSECOFR 33792 07/24/98 08:04:55 *DIR NetStationRmtController/ List completed.
ftp> MKD (directory - name) NetStationRmtController Created directory /qibm/proddata/os400/netstationrmtcontroller
ftp> cd NetStationRmtController Current directory changed to /qibm/proddata/os400/Netstationrmtcontroller.
ftp> ascii Representation type is ASCII nonprint. ftp> put LoadList.file PORT subcommand request successful. Sending file to /qibm/proddata/os400/Netstationrmtcontroller File transfer completed successfully.
Your TCP/IP configuration will depend on your specific environment.
* * t 6 Config>protocol ip Internet protocol user configuration IP config>list bootp BOOTP forwarding: enabled Max number of BOOTP forwarding hops: 4 Min secs of retry before forwarding: 0 Configured BOOTP servers: 192.9.220.21 IP config>
IP config>enable bootp Maximum number of forwarding hops [4]? Minimum seconds before forwarding [0]? IP config>
IP config>add bootp-server BOOTP server address [0.0.0.0]? 9.37.121.6 IP config>
Config>protocol ip
Internet protocol user configuration
IP config>list addresses
IP addresses for each interface:
intf 0 9.37.177.97 255.255.248.0 Local wire...
intf 1 192.9.220.2 255.255.255.0 Local wire...
intf 2 192.9.250.6 255.255.255.0 Local wire...
intf 3 192.9.222.2 255.255.255.0 Local wire...
intf 4 IP disabled...
intf 5 IP disabled...
intf 6 192.9.223.2 255.255.255.0 Local wire...
IP config>
IP config>set internal-ip-address Internal IP address [192.9.223.2]? 192.9.250.6 IP config>
IP config>list addresses
IP addresses for each interface:
intf 0 9.37.177.97 255.255.248.0 Local wire
intf 1 192.9.220.2 255.255.255.0 Local wire
intf 2 192.9.250.6 255.255.255.0 Local wire
intf 3 192.9.222.2 255.255.255.0 Local wire
intf 4 IP disabled
intf 5 IP disabled
intf 6 192.9.223.2 255.255.255.0 Local wire
Internal IP address: 192.9.250.6
IP config>
Before the Thin Server feature can be configured, you must add the load package.
First, check to make sure that the thin server package is available.
Config>load list available Available Packages ------------------ appn package tn3270e package thin-server package Config>
If it is not available, then you need to get the correct software version before proceeding.
If it is available, verify that the package is not already loaded.
Config>load list configured Configured Packages ------------------- thin-server package Config>
If it is already loaded/configured (as shown above), then you can proceed to configuring TSF. If it is not already loaded, then you need to add the Thin Server package:
Config>load add package thin-server thin-server package configured successfully This change requires a reload. Config>
If you had to add the Thin Server package, then you must now write the configuration and reload the IBM 2216.
When the package is loaded, the Thin Server is initially disabled. The mode must be set to enable, disconnected, or passthru before any other Thin Server parameters can be configured.
* * t 6 Config>feature tsf Thin server config>set mode enable Thin server feature (TSF) is fully enabled once you have entered a Master File Server for either RFS or NFS. Please add a master-file-server if one is not already configured. Thin server config>
Once the Thin Server feature is enabled, the master file server must be configured. In this example, the master file server is an AS/400 so we will add an RFS master file server. For this network, the default TFTP timeout and retry parameters are adequate.
Thin server config>add master-file-server rfs-as400
File Server IP address [0.0.0.0]? 192.9.221.21
Secondary File Server IP address [0.0.0.0]? 192.9.225.20
Master Server Refresh Retry Limit (1 - 20) [10]?
TFTP Packet Timeout in seconds (5 - 10) [5]?
TFTP Max Retry Limit (1 - 10) [1]? 7
TFTP Max Segment Size in bytes (valid values are 512, 1024, 2048, 4096, 8192)
[8192]?
Pre-load File name
[/QIBM/ProdData/OS400/NetstationRmtController/Loadlist.file]?
Thin server config>
Our AS/400's IP address on the Token-Ring interface is 9.37.100.68. When we installed the pre-load list file onto the AS/400 we assigned its name to match the Thin Server default name, so that does not need to be modified.
The default for the time of day to perform the refresh is 1:00 AM. This was chosen to minimize any performance impacts if large files have been modified and need to be downloaded by the Thin Server.
The default interval for verifying the cached files are at the same level as the master-file-server is every day. The value for this parameter and the time-to-refresh-pre-load-list parameter determine how often the files are verified. If the network station files change infrequently, then perhaps you would want to set these to only refresh once a week or once a month.
The default memory of a 16-MB RAM cache for file caching should be sufficient. Once several Network Stations are using TSF, see "Configuration Recommendations" for recommended values.
A hard-file is recommended. If you do not have a hard file, then this parameter should be set to no.
The default value is primary. If you have a secondary master file server, you may want to specify automatic selection. See "File Cache Updates" for details.